Retrievability SLA smart contract

When a storage customer stores data in an SP and sets up an SLA for retrievability, it pays FIL into the SLA smart contract, which will then be used to periodically verify retrievability of the data, through Retrieval Verifiers. Verifiers are rewarded for successful verification, as verification is expensive.

sequenceDiagram
  autonumber
  participant SPC as Storage Customer
  participant SLA as SLA Smart Contract
  participant RV as Retrieval Verifier
  participant SP as Storage Provider
  SPC->>SLA: FIL for periodically verifying retrievability
  SLA->>RV: Assign check
  RV->>SP: Retrieve data
  RV->>RV: Verify data
  RV->>SLA: Publish proof
  SLA->>RV: Reward proof
  SPC->>SLA: Verify proof existence
  

Motivation

I see two ways to approach retrieval testing:

1. Retrieval testing for the whole network. After data has been sealed, you want to know if it can be retrieved. At this point in time, you usually don’t also have the data available locally

2. Retrieval testing as part of an SLA. During deal making, the SP makes a commitment to retrievability over time, and proofing the same. At this point in time, you have the data available locally, and can therefore create more efficient proofs.

The SLA route should be more convenient to implement, since data is available locally and better proofs can be created.

Attack vectors

To prevent SPs from only serving verification requests, they mustn’t be distinguishable from other retrieval requests.

More TBD